Also note old behaviour was not stable/correct for negative (now fixed with PR&dropna):

In [9]: g.nth(-3,)
Out[9]:
               B
A
1  2.144760e-314
5  2.124748e-314

In [10]: g.B.nth(-3,)
Out[10]:
A
1    2.144760e-314
5    2.144337e-314
Name: B, dtype: float64

If you get around to it; I suspect the new method is MUCH faster than the old, so maybe add a vbench

will append a vbench. Is much faster except when applying to dataframe with dropna (old-style) it's a little slower, but that was previously borked.

Um, obviously there is overlap with first and last methods, they be got with nth(0) and nth(-1) but not tested the differences yet... you reckon these should change too?

yes I think you should blow away first/last code and just alias them to nth(0) and nth(-1).

reminds me that pls put some tests that deal with different types (because first/last have this convert arg..though not sure why)

though maybe nth(0) (first) and (iloc[0]) deserver a fast-path as it doesn't need the machinery of cumcount

there was/is a weird test for types of first/last/nth, I tweaked it a little but is still there...

I can iterate tests over a few of the same df (but with different column types), is that what you mean?

Yea, re fast path (will see how they compare the the cumcount for now)...

Added vbench, is about 40 times faster with not-including the setup of the groupby (which is included in the bench)

awesome!